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specification 

Background 

Cross Reference to Related Applica-tion 

This application is related to, incorporates by 
reference, and claims priority to the filing date of the 
following application filed by Finch, et al.: "TIME KEEPING 
AND EXPENSE TRACKING SYSTEM HAVING CUSTOMIZED GRAPHICAL USER 
INTERFACES", said application having been filed on January 
31, 2000 and having a serial number of 60/179,218. 
This app/ication is related to and incorporates the following 
applications by Finch et al . bei/g filed concurrently 
herew/th : 

1. "METHOD AND APPARATUS foR WIRELESS WEB TIME AND 
EXPENSE ENTRY VIA TIME KEEPING /nD EXPENSE TRACKING SERVER 
ACCESS"; 

2. "METHOD AND APPARjytuS FOR A WEB BASED PUNCH 

CLOCK/TIME CLOCK"; 

3. "METHOD AND APPARATUS FOR WIRELESS WEB TIME KEEPING 
AND EXPENSE ENTRY Wi/h A CALENDAR PROGRAM/ PERSONAL 
ORGANIZER" ; 

4. "METHOD AND ^PARATUS FOR PROVIDING PROMPT PAYMENT 
FOR TIME ENTRIES ENTERED BY WAY OF A TIME RECORDS SYSTEM"; 
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5. "METHOD AND APPARATUS Fo/ MONITORING CONTRACTOR 
PERFORMANCE"; 

6. "A TIME KEEPING AND EXPANSE TRACKING SERVER THAT 
GRANTS ACCESS TO RECORDS BAS^ UPON A USER'S ATOMIC 
ABILITIES"; 

7. "A TIME KEEPING AND I^XPENSE TRACKING SERVER THAT 
INTERFACES WITH A USER BASED l/pON USER'S ATOMIC ABILITIES"; 
AND 

8. "METHOD AND APPARATj/s FOR UNIQUELY IDENTIFYING HARD 
COPY TIME SHEET FOR 'CROSS RE^RENCE TO SYSTEM RECORDS". 

1. Technical Field 

The present invention relates generally to computer 
based time keeping and expense tracking systems, and more 
particularly to such a system that may be customized on an 
entity, group, project, user or other basis. 

2 . Related Art 

The tracking of workers' time has been required since 
workers began working on an hourly basis. An early example 
of hourly time tracking was the punch clock system in which a 
time card was assigned to each worker. Upon commencing work, 
the worker had his or her card punched by a clock so that the 
, work starting time could be recorded. Then, upon ceasing 
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rk, the worker had his or her card punched again so that 
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the work ending time could be recorded. From these starting 
and stopping times, a record could be constructed for a 
larger t;ime period, e.g., a weekly period, a bi-weekly 
period, etc. This record was then used in preparing a 
5 paycheck for the worker and in creating other records 
relating to the time worked by a partial or complete work 
force. 

While the punch clock system worked admirably in a 
factory environment in which all workers worked in a single 
10 location, time keeping was more difficult where a workforce 
was distributed. For example, employment agencies specialize 
in placing workers in contract positions within different 
organizations that also have their own employees. A contract 
employee, while being paid by an employment agency, reports 
15 to an employee (usually a supervisor) within the company. 
The contract employee creates a time sheet based upon the 
work he or she performs and then passes the time sheet to his 
or her supervisor at the company for approval. When the 
supervisor approves the time sheet, the supervisor passes the 
20 time sheet to the employment agency. The employment agency 
then receives the time sheet and typically inputs the time 
sheet into a computer that produces a paycheck for the 
employee and bills the company for the employee's time. 'This 
process is slow, tedious, prone to errors and expensive. The 
25 cost of the overhead associated with this process may easily 
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exceed twenty percent of the revenue that the employment 
agency receives for the employee. 

Another difficulty relating to time keeping relates to 
distributed work forces. Distributed work forces are now the 
5 norm, instead of the exception, not only for employment 
agencies but for companies as well. In a distributed work 
force, employees/contractors may be distributed worldwide. 
Each employee/contractor is required to submit time sheets 
for each pay period. These time sheets are received at a 
LO central accounting office, the time entries contained 
thereupon are then input into a computer system, paychecks 
are produced, reports are produced, and invoices are produced 
when required. While faxing or emailing time records to the 
central accounting office may expedite these operations, 
15 substantial effort must be expended in the process. 

organization of time records is another difficulty faced 
in time keeping. While all employees may work for a single 
company, the employees may work for different divisions, in 
different departments, and for different supervisors within 
the same department. Time records must be segregated 
according to this organizational structure for accounting and 
budget tracking purposes. Further, in an employment agency 
scenario, the employment agency may service tens or hundreds 
of companies. While each of the contractors works for, and 
is paid by the employment agency, invoices must be submitted 
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to the appropriate company. Further, within a particular 
company, a single contractor may work on more than one 
project, in more than one division, and for more than one 
supervisor. The contractor's time must be segregated 

5 accordingly when the invoice is submitted. To further 
complicate this effort, the contractor may be paid at 
different rates for this work, depending upon the project, 
division, etc. These complexities further increase the 
difficulty in not only paying the employee but in generating 
10 an invoice for the company. 

Expense tracking includes its own difficulties, some of 
which are shared with time tracking. Expense reports must be 
prepared on a periodic basis for each member of a. workforce, 
whether he or she is an employee or contractor. These 
15 expense reports must be received by an accounting department, 
allocated to the proper account, and reimbursement checks 
must be prepared. With a distributed workforce, at least 
those difficulties described above apply. Proper accounting 
of expenses and invoicing when required also introduces 
20 difficulties to the process. As may be seen, current systems 
do not readily facilitate time entry and monitoring for 
modern workforces that have employees that are continuously 
going from site to site. 

25 Thus, there is a need in the art for a timekeeping and 
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expense tracking system that overcomes the shortcomings cited 
above as well as other shortcomings of the prior systems. 
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SUMMARY OF THE INVENTION 

Thus, to overcome the shortcomir/gs of the prior systems, 
among other shortcomings, a timekeef^ing and expense tracking 
("TKET") system constructed according to the present 
invention provides a plurality of users with the ability to 
access the system via the Anternet and via wireless 
communication networks. The /tkET system resides upon at 
least one server computer yboupled to the internet and 
supports access from co/puter systems, web enabled 
telephones, personal data/ terminals, and other enabled 
devices including wirele4s personal digital assistants 
(PDAs) . The TKET system ymay therefore be accessed from both 
wired and* wireless devicy4s. In one embodiment, users employ 
browser software to acybess the TKET system and require no 
specialized client softfware. 

In order to support the many and varied needs of 
companies using the TKET system, the TKET system supports 
configurable graphical user interface screens ("GUI screen"). 
GUI screens are those displays provided to users of the TKET 
system when the users access the TKET system. Via the GUI 
screens, the users input their time and expense records. The 
GUI screens are configurable to alter the objects presented, 
the layout of the objects and information presented, the 
color schemes presented, the timekeeping or expense tracking 
information required from the user, and in other ways that 
cause the TKET system to be more effective. 
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GUI screens may be customized on a company-by-company 
basis, a department-by-department basis, a group-by-group 
basis, a project-by-project basis, and a user-by-user basis 
or upon another basis. A single TKET system may be used to 
service the time keeping and expense tracking needs of a 
plurality of companies, each of which has a- plurality of 
divisions, a plurality of departments, a plurality of groups 
and a plurality of employees/contractors. Thus, the 

configurability of the TKET system allows differing GUI 
screen presentations to be created and presented such that 
each group of users is employing a different system. 

GUI screen preferences for sets of users of the TKET 
system may be organized in a hierarchical basis to simplify 
the GUI screen creation and presentation operations. In a 
GUI screen preference hierarchy, a top level of the hierarchy 
possesses a respective set of GUI screen preferences that are 
sufficient to create a user's GUI screen. Each lower level 
on the hierarchy also possesses a respective set of GUI 
screen preferences. Each user serviced by the TKET system 
resides at a particular location on the hierarchy. With this 
hierarchy position determined, a GUI screen may be created 
for the user. In creating the GUI screen, the user's 
location in the hierarchy determines his ability level for 
making changes because he inherits the GUI screen preferences 
of all other higher level users in the hierarchy. However, 
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GUI screen preferences of successively lower levels of the 
hierarchy displace conflicting GUI screen preferences of 
higher levels of the hierarchy. Thus, a GUI screen for a 
particular user of the TKET system will have his or her GUI 
screen preferences determined along a top to bottom hierarchy 
path. 

The TKET system also generates GUI screens depending 
upon the type of terminal from which a user accesses the TKET 
system and the connection over which the user accesses the 
TKET system. A GUI screen created for the user when the user 
accesses the TKET system from a palm-top computer is simpler 
than a GUI screen created for the user when the user accesses 
the TKET system from a desktop computer. Further, when the 
user accesses the TKET system from a wireless device, the 
bandwidth of the available data path from the TKET system to 
the user's terminal will also be considered. A less complex 
GUI screen will be created and provided to the user when 
lesser bandwidth is available over which to transmit the GUI 
screen to the user. This operating feature is particularly 
important when the user accesses the TKET system from a 

wireless device. 

The invention further includes interfacing the TKET 
server with a calendar application that is hosted on a user 
terminal that comprises either a desktop computer, a laptop 
computer or a personal digital assistant (PDA) . In one 
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embodiment of the invention, the TKET server communicates 
directly with the calendar application if the TKET server 
knows the communication protocol for the specific calendar 
type. In another embodiment of the invention, an application 
is installed into the user terminal that serves as an 
interface between the TKET and the calendar application. 

Other aspects of the present invention will become 
apparent with further reference to the drawings and 
specification, which follow. 



Docket No. JOUR 007 



Brief Description of the Drawings 

A better understanding of the present invention can be 
. obtained when the following detailed description of the 
preferred embodiment is considered in conjunction with the 
following drawings, in which: 
5 FIGURE 1 is a system diagram illustrating a multimedia 

electronic mail system constructed and operating according to 
the present invention. 

FIGURE 2 is a functional block diagram illustrating a 
TKET server coupled to a user terminal according to the 
10 present invention, 

FIGURE 3 is a functional block diagram that illustrates 
an expanded TKET server system coupled to a user terminal 
according to one aspect of the present invention. 

FIGURE 4 is a software system configuration chart that 
15 illustrates to various software layers according to an 
embodiment of the invention. 

FIGURE .5 is a functional block diagram illustrating the 
relationship between users with respect to a TKET server 
formed according to the present invention. 
20 FIGURE 6 is a chart that illustrates the hierarchical 

relationship between different users wherein the hierarchical 
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relationships defined levels of ability to define the 
characteristics and arrangement of a GUI screen page 
according to a preferred embodiment of the invention. 

FIGURE 7 is an exemplary display of a GUI screen 
according to one embodiment of the invention. 

FIGURE 8 is an illustration ok a series of GUI screen 
screens that collectively illust/rate a concept of users 
having differing and relative le/els of atomic abilities for 
modifying the contents and arrangement of GUI screen screens 
according to one embodiment of /the invention. 

FIGURE 9 is a flow chart that illustrates a method 
performed by a TKET server for setting GUI screen preferences 
for a user. 

FIGURE 10 is a flow chart illustrating a method for 
generating a GUI screen page to a user and for receiving data 
inputs from the user for storing and processing. 

FIGURE 11 is a functional block diagram illustrating a 
TKET server in communication with a user terminal according 
to an alternative embodiment of the invention. 

FIGURE 12 is a table illustrating a method within a TKET 
server for generating a GUI screen display at a remote 
terminal according to a preferred embodiment of the 
invention . 

FIGURE 13 is a table determining whether to generate a 
set of signals for displaying either a full, reduced or 
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minimal GUI screen display based upon communication path 
characteristics according to one aspect of the present 
invention . 

FIGURE 14 is a flow chart that illustrates a method 
5 according to the present invention. 

FIGURE 15 is a flow chart illustrating an inventive 
method for receiving time tracking signals from a 
telecommunication switch according to a preferred embodiment 
of the invention. 
10 FIGURE 16 is a functional block diagram illustrating a 

network for facilitating timely electronic time entries and 
approvals according to a preferred embodiment of the 
invention . 

FIGURE 17 is a flow chart illustrating a method for 
15 entering and approving time entries according to a preferred 
embodiment of the invention. 

FIGURE 18 is a functional block diagram illustrating the 
circuitry within a time keeping and expense entry server 
according to one embodiment of the present invention. 

20 
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Detailed Description of the Drawings 

FIGURE 1 is a system diagram illustraying a time keeping 
and expense tracking (TKET) system ISO constructed and 
operating according to the present inven/tion. A TKET server 
102 couples to the internet 104 (world Wide Web) and 
converses with all other devices using one or more packet 
switched protocols supported by tflie internet 104. A 
telephone network 106 (which may /be the public switched 
telephone network ('"PSTN") or a/iother telephone network 
couples to the internet 104 via a gateway 108. Further, a 
wireless network 110 couples tfo the internet 104 via a 
gateway 112. The manner in whicfch the internet 104 (or other 
packet switched networks) couriles to the telephone network 
106 and to the wireless network 110 is generally known. 
Thus, the interaction betweeyi the internet 104 and the other 
networks 106 and 110 will hJk described only as it relates to 
the present invention. / And, of course, the structure 
illustrated in FIGURE 1 / is an example structure. Other 
structures may be constructed and operate according to the 
present invention to / support time keeping and expense 
tracking operations. / 

Computers 114 and 116 couple to the internet 104 and may 
interact with the TKET server 102 through this connection. 
While computer 114 has a direct connection to the internet 
104, computer 116 must access the internet via an internet 
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Service Provider (ISP) 118. Many users currently access the 
internet via an ISP, as illustrated with the connection for 
computer 116. However, some computers ciiirrently access the 
internet via an Intranet or other coupling network. In this 
construction, an ISP may not be required. Further direct 
connections to the internet are alr^dy possible such as 
shown with computer 114. Thus, simpl/ stated, the structure 
illustrated in FIGURE 1 provides a pAatform of operation for 
the present invention but must not/ be constructed to limit 
the teachings of the present invenyion. 

Web-enabled telephones 124/ and 12 6 couple to the 
telephone network 106. These ytelephones 124 and 126 each 
have displays upon which a GUI ficreen may be presented to the 
user. The' telephone network 12y4, as was previously described, 
15 may be the PSTN, which transmits data in a PCM format. In 
another embodiment, the telej^hone network 124 may be a packet 
switched network that supports packet-based communications. 
The teachings of the pr/sent invention, therefore, apply 
equally well to curreyfit or future telephone network 
20 technology. 

Wireless devices ijZO , 121 and 122 wirelessly connect to 
the wireless network llO. The wireless network 110 may be 
cellular based, satellite based or otherwise structured to 
provide wireless comi^lunication service within a service area. 
25 Wireless device 12^ is a portable computer that services 
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communications over a wireless link tc/ the wireless network 
110. Wireless devices 120 and IfZX are personal data 

assistants that wirelessly communiy6ate with the wireless 
network 110. The wireless network /llO communicates with the 
internet 104 via the gateway 112 

A local area network/wide /area network (LAN/WAN) 128 
couples to the internet 104 via/a firewall 130. At least one 
computer terminal, e.g., computer 132, couples to the LAN/WAN 
and may communicate with the /TKET server 102 via the LAN/WAN 
10 128 and the internet 128. fhe LAN/WAN may be supported by a 
company, a service provider /or another organization. 

The TKET server 102 may be operated by a single company 
or a plurality of companies that use the TKET server 102 to 
support its timekeeping/expenses. Alternately, the TKET 
15 senver 102 may be operated by an application service provider 
(ASP) that sells timekeeping and expense ^ services to a 
plurality of customers. The timekeeping services provided by 
the ASP may be bundled with other services so that the ASP 
provides a suite of services to its customers. 

According to the present indention, a plurality of users 
accesses the TKET server 102/ via differing communication 
paths and using differing terminal devices. Time and expense 
information is uploaded froi/ the terminal devices to the TKET 
server 102 where it is /tored and later used to generate 
25 invoices, paychecks, reports, and other alternate records. 
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Because the TKET server 102 is aofcessible from any location 
having internet 104 access, the/ TKET server 102 provides 
ubiquitous service worldwide. /hus, the TKET server 102 as 
easily services distributed woj^forces as it does centralized 
work forces. For example users at terminal devices 120, 132 
126 and 116 may work for k single employer/contractor at 
differing physical locationaf. However, in reporting time and 
expense information, they /simply access the TKET server 102 
via respective network comiections. 

A single user may use multiple and differing terminal 
devices to access the TKET server 102. Because of this, the 
user is not precluded from entering his or her time from a 
single terminal device. While the user is traveling, he or 
she may use a portable computer 122 or personal data 
assistant 121 to enter time. However, while working or at 
home, the user may use his or her personal computer. 114 to 
enter time and expense information. Thus, as compared to 
prior timekeeping/expense systems, the TKET server 102 
provides a centralized service environment that is not 
limited by the users' equipment. 

The design of the present invention is particularly 
advantageous in that it allows an employer to monitor time 
keeping and expense tracking in a real-time manner. Stated 
differently, by requiring an employee to access the system to 
enter his start and stop ties, the system serves as a time 
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clock. Moreover, the system includes the flexibility of 
allowing an employee (user) to enter previously worked by un- 
entered time. For example, an employee may need to enter 
travel time. 

5 With respect to the time clock feature of the invention, 

a GUI screen for a user of a wireless PDA terminal 121, for 
example, may have separate objects for start and stop times. 
Thus, the PDA may be programmed to establish a connection 
with the TKET server and to automatically upload a start or 
10 stop time when so requested by the user. With the present 
system, a PDA may serve as a portable time clock for the user 
to help him track his time. 

Continuing to refer to FIGURE 1, TKET server 102 
generates communication signals 134 that are to be delivered 
15 to any one of' the plurality of terminals shown in FIGURE 1. 
The communication signals 134 are created in a form to 
trigger terminal user software to generate displays 
containing information defined within communication signals 
134. For example, communication signals 134 may include 
20 signals in a form that trigger and that can be used by a 
plurality from terminal software to create a GUI screen. The 
form of the communication signals 134 and the content therein 
directly affect the display at the receiving terminal. For 
example, communication signals 134 actually comprise a large 
25 number of signals or information that result in a specified 
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GUI screen being displayed on the terminal display. Thus, 
either for a terminal having a limited capacity for receiving 
and handling large amounts of information or for a network 
path having low bandwidth data throughput capacity, the 
magnitude or total amount of signals that comprise 
communication signals 134 will be reduced thereby resulting 
in the display of a reduced GUI screen page. In the case, by 
way of example, of a mobile terminal, the signals within 
communication signals 134 may be so limited that little more 
than text is transmitted to the terminal. 

The communication signals 134 also include control 
information to prompt the receiving terminal to generate a 
response indicating a user selection of options or questions 
asked within the GUI screen for the response signals 136 are 
received by TKET server 102. 

For most user terminals, the respfonse signals 136 use 
the hypertext transfer protocol (HTt/) that is used by web 
servers and client browsers to corrtaunicate over the World 
Wide Web. Generally, the pro1^>col is used for moving 
documents around the internet/ Additionally, terminals 
usually employ hypertext mark-Zp language (HTML) for creating 
World Wide Web pages. Accoi^^iingly , the TKET server 102 can 
estimate the capabilities /of. the terminal, and perhaps the 
transmission data path /rom the HTTP and HTML information 
that is received as a part of response signals 136. As will 
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be explained in greater detail heryfein this application, TKET 
server lOZ determines the charac/eristics of the GUI screen 
display that are to be created bL the user terminal according 
to the content of response sianals 136. In addition to the 
5 HTTP and HTML information firom which TKET server 102 may 
infer terminal or communicayt ion path capabilities, an actual 
synchronized address selection by the user to which response 
signals 136 are being routed may be used, in an alternate 
embodiment, by the TKE*/ server 102 in determining GUI screen 
10 display characterist i/s . Alternatively, response signals 136 
may merely include /an indication of a user selection from 
which a correspondylng GUI screen display is generated. 

Other factors are also used by TKET server 102 to 
determine what GUI screen display signal characteristics are 
15 appropriate. By way of example, the TKET server 102 is 
operable to determine the number of gateways in the 
transmission path between it and the user terminal from 
examining the http information associated with a received 
signal. For example, the network of Figure 1, a Gateway 108 
20 is shown to exist in the path between TKET server 102 and 
telephones 124 and 126 of telephone network 106. Between 
TKET server 102 and user terminal 122, there not only exists 
a Gateway 112, but also a wireless network 110 that 
introduces substantial propagation delays. Accordingly, by 
25 determining how many Gateways exist in the path and other 
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characteristics of the path such as whether the communication 
signals are being routed through a telephone network 106, a 
local area or wide are network 128, or a wireless network 
110, as well as the number of Gateways through which 
communication link passes, TKET server 102 is able to 
determine an approximate value for through put capacity. For 
example, merely having to go through a wireless network 110 
might, in the described embodiment, result in TKET server 102 
transmitting, at most, a reduced set of display signals for 
forming a reduced GUI screen display. 

FIGURE 2 is a functional ]?)lock diagram illustrating a 
TKET server coupled to a user terminal according to the 
present invention. A user ycerminal 204 communicates with 
TKET server 208 by way of i/terface 212. Interface 212 may 
comprise any combination /of an ISP, a gateway and an 
internet, a wireless network, a PSTN or any other 
communication network. /tket server 208 also is coupled to 
database 216 that is fpr storing user information including 
user selected GUI screen display parameters. 

TKET server 208 comprises a session interface module 
220, a GUI screen definition module 224 and a GUI screen 
display module 228. Each of these modules operates in 
concert to support the disclosed invention herein. To 
illustrate, GUI screen definition module 224 is for storing 
default GUI screen page parameters and GUI screen display 



22 



Docket No. JOUR 007 

definition information for creating GUI screen pages on a 
user terminal display. Additionally, module 224 includes 
information for defining logic for rearranging, renaming, 
adding, and deleting time entry or expense tracking 
components. The specific logic contained therein is better 
explained in the discussion of the figures that detail 
operation of the invention. 

The inventive system is operable to enable a user to 
customize the GUI screen displays to a degree not seen in 
other display systems, and more particularly, in time and 
expense tracking systems. To enable the user to select 
display parameters, the inventive system includes a GUI 
screen display module 208 that creates GUI screen displays 
according to the definition information stored in GUI screen 
definition module 224. Additionally, GUI screen display 
module includes logic for creating displays according to the 
display parameters selected by the user that are stored 
within database 216. 

Database 216 is for storing customized display 
parameters selected by a user. For example, the number, 
arrangement and names of elements within the rows and columns 
of a GUI screen display page on a per user basis are stored 
within database 216. In the preferred embodiment of the 
invention, database 216 is for storing multiple display pages 
for each user that requires multiple pages. 
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By way of example, a user may want to define multiple 
GUI screen pages for display on his terminal screen according 
to the terminal type. If the user, for example, typically 
accesses his time and expense tracking system either with a 
PDA or with a desktop computer terminal, his display 
capabilities will . vary according* to the capacity of the 
terminal in terms of bandwidth, memory, and display 
processing throughput capacity. Accordingly, database 216 is 
formed to include software instructions and memory capacity 
to store multiple GUI screen display pages according to user 
need and GUI screen display module 208 is formed to include 
logic for selecting between the multiple GUI screen pages. 

In addition to database 215 that stores multiple display 
pages for each user, session interface module 220 is for 
determining the terminal type through which the user is 
accessing the TKET server 208. More specifically, session 
interface module 220 includes software instructions that 
define logic for determining the bandwidth and terminal type 
of the user terminal. The session interface module 220, in 
one embodiment, produces a GUI screen selector signal for the 
GUI screen display module 228 to determine what GUI screen 
display is to be created for the user terminal 204 the GUI 
screen selector signal. 

There are many different ways in which the session 
interface module 220 may determine the user terminal type. 
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In one embodiment of the invention, the user specifies his 
terminal type by selecting a corresponding URL when accessing 
the TKET server 208. By way of example, the user is 
instructed to use a first URL for accessing the TKET 208 when 
5 the system is being accessed with a PDA and a second URL when 
the system is being accessed with a desktop or laptop 
computer . 

In another embodiment of the invention, a terminal ID is 
transmitted to the TKET server 208 that identifies the 

10 terminal type. For this embodiment, session interface module 
examines the contents of a database, e.g., database 216, to 
determine the terminal type based upon the terminal ID. In 
yet another embodiment of the invention, the user is given an 
option to select from one of several GUI screen display 

15 modes. For example, the user may be given the option to 
select either a FULL or REDUCED GUI screen display wherein 
the display modes relate to the capacity of the user display 
terminal . 

As another aspect of the invention, the session 
20 interface ID module examines the signal path through which 
the GUI screen page is to be delivered to the user terminal. 
For example, if the signal path includes a wireless branch, 
it may determine to transmit a GUI screen page that would 
have a smaller memory or data transport capacity requirement. 
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In yet another embodiment of the present invention, the 
session interface module transmits a signal to the user 
terminal to measure a response time. The GUI screen display 
module then selects GUI screen display page types according 
to the response time. For this embodiment, it is assumed 
that a response time corresponds to a network data transport 
capacity. Accordingly, a GUI screen page requiring the 
transmission of lesser amounts of data is selected for those 
network paths whose transport speed is lower. 

In operation, a user connects to TKET server 208 with 
his terminal 204 to enter or review time and/or expense 
information. Session interface module 220 determines the 
user terminal type, if necessary, by sending a message to the 
user to prompt the user to select a GUI screen display page 
type or mode. The GUI screen display module then builds and 
transmits a GUI screen display page based upon the GUI screen 
selector signal value created by the session interface module 
220 and based upon the user specific GUI screen page 
information stored within database 216. 

The above described embodiment includes having multiple 
GUI screen pages for each user, if necessary. In an 
alternate embodiment, each user defines only one GUI screen 
page. The parameters of the page include graphical 

information including unique fonts, color patterns, graphical 
symbols and related spacing and layout of all of these GUI 
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screen page elements and aspects. If, however, the GUI 
screen selector signal indicates that the user terminal has a 
reduced data capacity in terms of processing speed or memory, 
the GUI screen display module builds a GUI screen display 
page that, omits certain elements of the page. For example, 
if the user terminal type is a PDA having only black and 
while color capability, the GUI screen display module would 
build a GUI screen page without color information. 
Additionally, the GUI screen display module may build a GUI 
screen page that omits certain graphical signals. Thus, for 
this embodiment, the GUI screen page is said to be ^'implied" 
from the stored GUI screen page. 

In yet another alternate emboc^iment of the invention, 
the GUI screen display module buiLtis an implied page based 
upon on ' of several different usey created GUI screen pages 
stored within database 216. For /example, if the GUI screen 
selector signal indicates that the smaller (in memory size) 
of the two GUI screen pages is/ to be built for transmission 
to the user terminal, the GUI kcreen display module may still 
build a GUI screen page whosfe elements are implied from the 
selected GUI screen page. /to illustrate, the user may have 
selected a smaller GUI sc/een page, but based upon the user 
terminal type, the amount/ of information of the smaller GUI 
screen page may still/ exceed the capacity of the user 
terminal. Thus and even more limited GUI screen must be 
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created or ''implied" frZm the selected screen. For example, 
if the user terminal/ is a cellular device having limited 
display and at a pr/cessing capability, the GUI screen page 
may be reduced Xp being little more than a string of 
alphanumeric characters even though the selected server was a 
''REDUCED" GUI scleen. 

FIGURE 3 is a functional block diagram that illustrates 
an expanded TKET server system coupled to a user terminal 
according to one aspect of the present invention. The system 
of FIGURE 3 is similar to that shown in FIGURE 2 except that 
the TKET server of FIGURE 2 is replaced by a network of TKET 
servers. Primarily, the network of TKET servers shown 

generally at 300 illustrate that the components (individual 
TKET servers) of the TKET server network are coupled to 
communicate with each other to produce a scaleable TKET 
server network that can be formed to satisfy system 
requirements. As may also be seen, the TKET server network 
comprises application servers that are coupled to the users 
through a plurality of web servers. 

FIGURE 4 is a software s/ystem configuration chart that 
illustrates to various software layers according to an 
embodiment of the invention/ More specifically, the chart of 
FIGURE 4 illustrates re/ative arrangement and Each layer 
represents different leyels of abstraction with respect to 
the software and its functionality in a ' TKET server. 
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The lowest level layer i/s the database interface layer 
410. Database interface la/er 410, as its name implied, is 
the layer at which compute^ instructions cause a TKET SERVER 
processor to interact wit^ a database within a storage device 
to obtain specific Zser selected GUI screen display 
parameters as well as /stored user data. The second layer is 
the coarse object la/er 420. The course object layer 420 is 
the layer at which /the programmer can access a whole table of 
objects as one object. 

The third layer is the fine object layer 430. The fine 
object layer is the layer at which single objects represent 
one user, one project, or one such other object in the 
system. The fourth layer is the presentation layer 440. A 
presentation layer is a layer at which HTML, WAP or HDML is 
prepared for the user and user input is passed back to the 
program. For example, the computer instructions at the 
presentation layer are those instructions that prompt a 
processor to generate the appropriate type of GUI screen. 
The fifth layer is the common gate interface (CGI) script 
layer 450. CGI layer 450 is the layer at which presentation 
data is passed up to the web server. 

FIGURE 5 is a functional byock diagram illustrating the 
"elationship between users vr/th respect to a TKET server 
formed according to the present invention. TKET SERVER 504, 
an application server, i/s coupled to communicate with a 
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plurality of users by way of a communicatidh network. A user 
terminal 508 is coupled to communicate w/th TKET server 504 
and to receive GUI screen displays there/from. Additionally, 
user terminals 512 and 516 are coupled to communicate with 
TKET server 504. Dashed lines 520 and 524 are shown between 
user terminal 504 and user term/nals 508 and 512 to 
illustrate a business relationship /between the users of the 
respective user terminals. By way/of example, if the user of 
user terminal 504 desires to estq/blish a time management and 
tracking service and to establis/i a service relationship with 
the Operator of TKET server /504, then the user of user 
terminal 504 is, for the ifaurpose of this example, the 
administrator for the time i^anagement and tracking company. 
Thus, the users of terminals 512 and 516 are the clients of 
the user of terminal 504. 

In the illustration/ of FIGURE 5, there also exists a 
business relationship be/tween the users of terminals 512 and 
516. For simplicity^, an illustration of the business 

relationship betwee/f user terminals 528 and 532 and user 
terminal 516 isX shown. User terminal 512, has business 
relationships Aiith other lower ability users that are not 
shown hereir 

One reason that the business relationships are indicated 
in FIGURE 5 for exemplary purposes is to illustrate why each 
layer of users has different ability levels. Thus, for 
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example, user 508 may be an administrator for the time 
keeping and expense tracking function subscribed or used by 
each of the lower ability level users 512, 516, 528 and 532 
and supported by the operator of TKET server 504. Similarly, 
users 512 and 516 may be managers for the time keeping and 
expense tracking function. Users 528 and 532 may be mere 
users. Alternatively, they too may be managers having yet 
lower ability level users. For example, if each of the users 
528 and 532 represent a company, each company may have 
organizational units such as section, departments, or 
divisions that are lower ability level users. A better 
understanding of the abilities of the different level users 
is explained in the discussion relating to FIGURE 8 . 

FIGURE 6 is a chart that illustrates the hierarchical 
relationship between different users /wherein the hierarchical 
relationships defined levels of / ability to define the 
characteristics and arrangement/ of a GUI screen page 
according to a preferred embodd/hent of the invention. The 
chart of FIGURE 6 illustrates the relationship of three 
hierarchical ability levels oj£ users. The first hierarchical 
level shown generally at/ 604 represents an application 
service provider (ASP) thdt also serves as an administrator 
for the example shown he^rein. The administrator originally 
receives a GUI screen pa^e that is set up according to a 
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plurality of default settings. Being afdministrator , however, 
the objects of the GUI screen page ma^ readily be modified by 
the ASP/Administrator , 

The second hierarchical leve^ shown generally at 608 
includes five users 612, 616, 620/ 624 and 628, each of which 
may have additional lower /level users as shown at 
hierarchical level 632. Fcp: example, user 628 further 
includes four lower ability /level users 636, 640, 644 and 
648. While not shown specyfically herein FIGURE 6, each of 
0 the users of level 632 may/ also have additional lower levels 
users. For example, if each user of level 632 represents a 
different company, therye may still exists several lower 
layers according to the/ size of the company and the number 
and arrangements of the/ divisions of the company. 
5 Continuing to refer to FIGURE 6, each level of user 

receives a GUI screen page having a default arrangement and 
object labels and contents. According to the selections of 
all of the users above the present user in terms of what may 
or may not be modified, the present user may modify the 
0 arrangement and label values and well as content of the rows, 
columns and objects of the GUI screen page. A better 
explanation of the relative abilities of users is explained 
in the discussion of FIGURE 8 below. 

In general, however, each user receives a GUI screen 
5 page having a default set of values that is determined by the 
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higher level of users. Thus, the ASP/Administrator of group 
604 has a first set of default values. The users of group 
608 receive GUI screen pages whose default settings are 
determined by the ASP/Administrator 604. Similarly, the 
5 lower level users of group 632 receive GUI screen pages whose 
default values are determined by the ASP/Administrator and by 
the higher level user of group 608 to which the user of group 
632 belongs. For example, user 628 and ASP/Administrator 604 
determine the default settings of users 636, 640, 644 and 
10 648. In general, each hierarchical level of FIGURE 6 has a 
different set of GUI screen default settings according to the 
relative" placement of the user. 

While the table of FIGURE 6 illustrates only three 
levels of users, it is understood that there may be 
15 additional levels below the third level shown ■ generally at 
632. While there may not be any higher levels than shown in 
FIGURE 6, it generally is possible to have additional levels 
in either direction if the highest level shown is not the ASP 
as is the case in FIGURE 6. 

^ The hierarchical relationship ^tween the users affects 
more than screen definitions. /More specifically, access 
control lists may be defined thax specify access to specified 
information or lists of information. Generally, each user 
may transparently view the/ GUI screen screens of all lower 
25 level users. If a use/ belongs to multiple groups, for 
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example, wherein there are a pluraliycy of lower level users 
within each group, the user wil/1 have the ability to 
transparently review or even to mooiify the content of the GUI 
screen screens of the lower leve/ users in each group. Each 

review the GUI 
may not review 
or at higher 

hierarchical levels. In s^ch a case, the user is ^'hidden" 
from those users whose scyeens he cannot access. 
0 Moreover, because project codes are similar to expense 

accounts, it is often desirable to prevent the project codes 
from being viewed by lower level users in a selective manner. 
Thus, a user, e.g., a manager levels user, may select what 
codes may be viewed by the users in a given group through the 
5 access ' control lists. If a lower level user also acts as a 
manager for his lower level users, the upper level manager 
will have access to view the codes and access control lists 
defined and controlled by the lower level manager. 

The function of hiding project " codes may also be 
0 performed on a per user basis through the use of the access 
control lists. Thus, a manager may specify in an access 
control list those lower level users that have access to a 
given code. 

FIGURE 7 is an exemplary display of a GUI screen 
5 according to one embodiment of the invention. The screen of 



of the lower level users, however, can only 
screen pages of their lower level users. They 
the GUI screen pages of users at the same 



34 



Docket No. JOUR 007^^ 

FIGURE 7 includes five groups of information 702, 704, 708, 
712 and 716. As has been discussed above, different users 
have different ability levels in terms of the extent to which 
they may make selections for the characteristics of a GUI 
5 screen. The example of FIGURE 7 illustrates a screen that is 
observed by a user not having the highest ability level. 
Thus, the screen received by the user of the screen of FIGURE 
7 includes groups 702, 704 and 708 whose objects are not 
modifiable. By way of example, group 702 includes an object 

10 reserved for displaying a corporate logo while group 704 
includes an object of displaying a corporate name. Group 708 
includes at least one object that includes departmental 
identifiers. Similarly, group 716 includes an object for 
displaying a banner or advertisement that may not be modified 

15 by the user of the screen illustrated in FIGURE 7. 

The objects of group 712, however, are modifiable by the 
user of the screen shown in FIGURE 7. For the example 
herein, the objects of group 712 are for storing the actual 
time or expense entries. Moreover, the actual arrangement of 

20 the columns and rows of group 712 are modifiable. Thus, 
based upon user selection, rows may be displayed as columns 
or vice versa. Additionally, the actual names given to these 
rows or columns are modifiable. In the preferred embodiment 
of the invention, the screen is initially received by the 

25 user with a set of default names and values. Then, for each 
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row or column, the user may activate a pull down menu to 
select from one of a group of alternate names. In an 
alternative embodiment of the invention, the user may also 
type in a name if one of the alternative names does satisfy 
the user's requirements. For example, a row labeled as 
'"entertainment" may have alternate names including "dining'', 
'"alcohol", or "'sporting events". In the alternate embodiment 
of the invention, the user may choose to type a label that 
does not exist such as "Golfing Fees" if, for example, the 
user entertains clients on the golf courses. 

The TKET server 700 supports fully customizable GUI 
screens, which are the presentation, made to the user when 
requesting time entries and/or expense information. Each 
time entry typically includes at least five components: (1) 
an identity, e.g., the user's identity; (2) a corresponding 
date or date range for the time entry; (3) the duration of 
time for the time entry, or alternately starting and stopping 
times for the time entry; (4) elements of the time entry, 
e.g., project code, project sub-code (s), time categories and 
subcategories, etc., and (5) comments regarding the time 
entry. In the described embodiment, even the name, size and 
arrangement of the comments field (object) is configurable by 
the user. As may be seen from examining group 712 in FIGURE 
7, the top row of object titles represent the default 
settings that are provided by a higher level user while the 
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dashed objects below the top row of object titles represent, 
more generally, that a pull down menu may used to allow the 
user to select from a list of object names for each object. 

The chart of FIGURE 7 illustrates, therefore, a time 
entry GUI screen session for an employee having the lowest 
ability level/role for defining the screen display 
parameters. The objects of group 712 may be arranged by the 
user in any order or may even be renamed by the user. 

FIGURE 8 is an illustration of a ^eries of GUI screen 
screens that collectively illustrate / a concept of users 
having differing and relative levels ®f atomic abilities for 
modifying the contents and arrangement of GUI screen screens 
according to one embodiment of the /invention . Referring now 
to FIGURE 8, each of the three OTJI screen screens contains 
five rows and one column of objeats. In the first GUI screen 
810, it may be seen that all fi^e objects 811 through 815 are 
highlighted (as indicated by /the box around the object) to 
indicate that each of the oKjects may be modified. The GUI 
screen of FIGURE 8 is one toat is under the control of a TKEK 
server administrator haviiig the highest level of ability to 
modify the objects withi/n the screen. Accordingly, all five 
objects are modifiable by the user (administrator) . An 
access list stored wiychin the TKET server defines the access 
level of the user. / From the stored .information, the TKET 
server determines that all five rows are modifiable by the 
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user to whom the screosn 810 is to be transmitted. 
Accordingly, each of the yfive objects is sent in a format to 
enable the receiving user to make modifications. 

The screen shown at 820 shows the same five objects 511 
through 815 of screen 810 but that only objects 812 through 
815 are highlighted. That object 811 is not highlighted 
indicates that the user of screen 820 has a lower ability 
level and, more specifically, cannot modify the display or 
content of object 811. In general, if object 811 represents 
a value or symbol that the administrator does not want its 
lower level users to modify, then the contents of that object 
appear for all of the lower ability level users. 

The screen shown at 830 also includes the same five 
objects but only objects 813 through 815 are highlighted 
illustrating that the user of screen 830 may not modify 
objects 811 and 812. While object 811 was made un-modif iable 
for both of the lower ability users of screens 820 and 830, 
the user of screen 820 made object 812 un-modif iable for the 
user of screen 830. While not explicitly shown in FIGURE 8, 
it should be understood that there might well be additional 
screens that represent additional lower ability users. For 
example, the user of screen 830 may represent a company. In 
such a case, each of the lower ability screens would relate 
to organizational units of the company. No particular limit 
as to the number of ability levels is intended by the 
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illustration of FIGURE 8, which includes only three ability 
levels. 

Continuing to refer to FIGURE it may be seen that a 

reporter 840 is coupled to receLve each of the GUI screen 
screens 810, 820 and 830 from yche user terminals displaying 
them. A reporter may be any type of device that is for 
storing or displaying info3?mation of the type being supported 
on each of the GUI scree/i screens. By way of example, if the 
system of FIGURE 8 relates to time entry, the reporter may be 
a terminal and screeri of a supervisor that is monitoring the 
time entries of e4ch of the users of the three GUI screen 
screens 810, 82Q/and 830. Alternatively, the reporter may be 
a report generating routine stored within TKET server 102 (of 
FIGURE 1, tpx example) and executed- by a processor within 
TKET serve/ 102. 

While the example of FIGURE 8 includes an illustration 
of how objects* may be changed, it is to be understood that a 
user also may be allowed by a higher ability level user 
(e.g., a manager or an administrator) to change other 
features of the GUI screen including color, font type, etc. 
Moreover, as mentioned before with respect to FIGURE 7, even 
the lowest ability level user has the capacity to rename 
objects. Thus, for a reporter 840 to be able to meaningfully 
monitor the time keeping and expense tracking of the user, a 
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database or table is needed to map the changes made by the 
user from the default settings provided to him. 

The database or table thus enables the reporter to 
analyze numbers and add values from different users having 
different names but representing the same basic parameter. 
For example, one user may track a term named "Hourly value" 
while another user tracks a term name ''"Client cost'' wherein 
both numbers represent the amount that the client or project 
is to be charged for the contract employees time and effort. 
Thus, if the mapping of object names is found within database 
216 of FIGURE 2, for example, reporter 840 must communicate 
with database 216 to properly generate the time and expense 
tracking reports. 

FIGURE 9 is a flow char/t that illustrates a method 
erformed by a TKET server foy setting GUI screen preferences 
for a user. First, the TKEt/ server receives and establishes 
a connection with a user yand determines the user ID (step 
904). As was shown in FIGURE 1, the connection may comprise 
a path through any one of the public switched telephone 
networks, through a wiyreless network, through a local area 
network, through any one of the various internets or through 
any combination of these networks. 

After the connections is established, the TKET server 
determines the user's role and associated abilities for 
defining and modifying objects of a GUI screen (step 908). 
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* 

For example, if the user role is that of an administrator, 
the TKET may allow the user to make any change from an 
original default screen that is desired {unless, of course, 
the TKET server operator chooses to make one or more objects 
5 fixed (e.g., a small logo inconspicuously displayed). 
Alternatively if the user is a lower ability level user 
relative to the administrator, then the TKET server must 
determine the objects that the user is allowed to modify or 
change . 

10 Once the TKET server determines the user role and 

corresponding abilities, it provides the options to the user 
for making changes to the GUI screen page (step 912) . As 
indicated before, these options are options for modifying GUI 
screen display parameters of a default page. In an alternate 

15 embodiment, however, a default page is not provided for the 
highest ability level user. For this embodiment, the highest 
level user (administrator) must define the layout of the GUI 
screen page. The default page of course is the page settings 
created by a user that is one ability level higher than the 

20 present user and includes the selections of all users that 
are at a higher ability level than the present user. In the 
case of the highest ability level user (e.g., an 
administrator) , the GUI screen default page is created by the 
operator of the TKET server for the purpose of providing the 
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administrator a starting point for creating and defining his 
GUI screen page. 

Thereafter, the TKET server receives the user's GUI 
screen page definitions (step 916) . The definitions can be 
5 in the form of fixed data values, text (e.g., formulas for 
making calculations that are to be displayed) , and row and 
column names, row and column arrangements. 

After each GUI screen definition is received, the 
invention includes accepting and modifying the GUI screen 

10 definitions from the default value (s) (step 920). This step 
' includes storing the received GUI screen definitions with 
respect to the user ID. After each GUI screen definition is 
received, the invention includes determining whether the user 
is through making changes and defining his GUI screen or 

15 whether to present the GUI screen modification options to the 
user once again to receive more changes (step 924) . For 
example, the TKET server may transmit a signal asking the 
user if he has more changes to make. Based upon the 
response, either step 912 is repeated or the inventive method 

20 of FIGURE 9 is complete. 

Each of the above steps for creating a GUI screen page 
may be performed multiple times to create multiple GUI screen 
pages. For example, a user realizing that he will want to 
access the GUI screen page from two different terminals, each 

25 having significantly different data handling capacity, may 
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want to define a GUI screen page for each of the two 
terminals. Accordingly, when the user logs into the GUI 
screen server, he is able to select the desired GUI screen 
page . 

FIGURE 10 is a flow chart illustrating a method for 
generating a GUI screen page to a user and for receiving data 
inputs from the user for storing and processing. Initially, 
when the user logs in, the TKET server examines the user ID 
so that it may determine the necessary information for 
generating a GUI screen page to the user (step 1004). 
Thereafter, the TKET server determines the group IDs and 
memberships that correspond to the user ID received from the 
user (step 1008) . 

As a part of determining how to/ set up a GUI screen 
page, the invention includes detefrmining what type of 
communication channel is to be -useia to transmit the created 
GUI screen page (step 1012). For/example, this step includes 
determining whether the GUI scr/en page is to be transmitted 
via wireless data link, through a low bandwidth serial line 
by way of a modem such as/ a typical 56K byte/sec desktop 
computer modem, or through high speed serial digital 
communication link uti/Lizing a Tl or T3 line. More 
generally, this step yhcludes determining the data throughput 
capacity of the data/link for slowest known data link between 
the user terminal and the TKET server. 
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Knowing the data throughput capacity by determining the 
type of communication channel is important for determining 
what features to include in the page for transmission to the 
user. < One part of determining data throughput capacity of 
the data link is determining what the appropriate protocol 
for generating and transmitting the page should be. For 
example, hypertext markup language (HTML) is appropriate for 
a full GUI screen page being transmitted to a desktop 
terminal. Similarly, hand held device markup language is 
appropriate for PDAs and other hand held devices while 
wireless application protocol (WAP) is appropriate of 
wireless devices or terminals. 

Finally, in order to determine the characteristics of 
the GUI screen page that is to be created, the TKET 
determines the terminal type (step 1016) . For example, if 
the terminal type is a PDA, its capacity for receiving GUI 
screen displays having color information will likely be 
notably lower' than the capacity of a desktop computer. 
Similarly, if the PDA is to receive the GUI screen page over 
a wireless link, then the amount of information that may be 
transmitted must be reduced even further. Accordingly, a 
simpler GUI screen page should be created. 

In addition to the above steps of analyzing the system 
parameters that affect how much information may be used to 
form a GUI screen page for transmission to the terminal, the 
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inventive method includes determining what user profiles have 
been previously defined for the user. Thus, the invention 
includes obtaining the user profiles that, in the preferred 
embodiment, are stored in a database and may be accessed by 
the user ID (step 1020) . Additionally, besides determining 
what the defined objects are for the user and how they should 
be arranged on a GUI screen page, the data content of the 
objects must be retrieved so that the GUI screen page may be 
populated with the user's data (step 1024). 

At this point, the TKET server has determined the 
necessary information for building the GUI screen page. 
Thus, the next steps include building the GUI screen page 
(step 1028), transmitting it to the user (step 1032), 
receiving data entries from the user for some of the various 
objects of the GUI screen page (step 1036) , and storing the 
data in a database (step 1040) . 

The above listed method steps for creating a GUI screen 
page according to network and user selected parameters may be 
practiced in one of several different manners. For example, 
in the described embodiment, the TKET server determines the 
type of GUI screen page that should be built for transmission 
to the user based upon transmission channel and terminal 
capacities. For this embodiment, the TKET server analyzes a 
user terminal ID to determine type of terminal. The user ID 
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may be selected and entered by the user or it may be embedded 
in a set of setup signals transmitted by the terminal. 

With respect to the transmission channel, TKET server 
analyzes the source of the incoming communication link. By 
5 way of example, if the communication link is received by the 
TKET server from a mobile switching center of a wireless 
network, then the TKET server determines that a wireless 
communication link is included in the communication path. In 
the described embodiment, the TKET server maintains a list of 

10 prefix numbers that identify the mobile switching centers. 
The list of numbers and their originating sources may be 
operated in a manner similar a telecommunication network 
service control point. 

In an alternate embodiment of the invention, the first 

15 time a user establishes a link to a TKET server for a 
session, the server merely sends a signal to the terminal to 
prompt it to generate an immediate response in order to 
measure a response time. By measuring the response time, the 
TKET server is able to roughly determine data transport 

20 capacity through the established communication link for that 
session. Accordingly, it is at least partially from this 
approximation that the TKET server selects the size and 
complexity of the GUI screen page that it builds for 
transmission to the user terminal. 
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In yet another embodiment of the invention, the TKET 
server initially selects one of a plurality GUI screen 
formats according to terminal type. Thereafter, GUI screen 
elements are implied according to the communication channel 
5 performance. For example, if the select GUI screen that 
corresponds to terminal type includes color information, but 
the communication channel response time does not allow for 
color information to be transmitted without incurring a delay 
beyond a specified amount, the TKET server may create an 
10 implied GUI screen that does not include color information. 
Thus, as may be seen, the invention includes determining the 
complexity of the GUI screen that is to be built not only by 
operator selection, but also by system capabilities or 
performance . 

15 The actual parameters that are to be selected or 

discarded for those embodiments in which a full set of GUI 
screen display signals is not to b e generated by the TKET 
server makes the determination may readily be modified 
according to implementation of the inventive methods herein. 

20 In general however, they include decisions about whether to 
transmit color information, whether to transmit graphical 
symbols, logos and designs or even font information, whether 
to transmit specified advertisements, and whether to transmit 
certain arrangement information. 

25 
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FIGURE 11 is a functional block diagram illustrating a 
TKET server in communication with a user terminal according 
to an alternate embodiment of the invention. Referring now 
to FIGURE 11, it may be seen that a TKET server 1100 is in 
communication with a user terminal having a display screen 
1104. As may be seen from viewing screen 1104, three URLs 
representing different display options from which the user 
may choose are being displayed. Each display option 
represents different display nodes. 

First, option 1108 labeled ''Full" is for enabling the 
user to select a full GUI screen display node. Option 1112 
is for enabling the user to select a reduced GUI screen 
display while option 1116 is for allowing the user to select 
a minimum display. The user selection is then transmitted by 
the user terminal in a user selection signal 1120 that is 
transmitted to TKET server 1100. A display module 1124 
within TKET server 1100 is operable to receive signal 1120 
and to generate display signals to create a GUI screen 
display responsive thereto. 

While the example of FIGURE 11 illustrates the user 
eing given URLs to select/ GUI screen display signal 
characteristics being transmitted by the TKET server, other 
approaches may be employed/ More specifically, the URLs are 
used to cause the communication link to establish a 
communication link to /n internet address. The TKET server, 

48 
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generates GUI screen display signal/ having characteristics 
that correspond to the URL. Thus, /for the example of FIGURE 
11, because three URL addresses /are shown, the TKET server 
has at least three different /sets of URL signal display 

5 characteristics to generate /responsive thereto. In an 

alternate embodiment of the ynvention, however, a GUI screen 
display may prompt the use/ to select from a plurality of 
display characteristics. The. user choice is then transmitted 
to the TKET server for Lt to generate GUI screen display 

0 signals having characteristics that are responsive thereto. 

In one embodiment of the invention, each of the options 
presented to the user on screen 1104 is one that triggers a 
different URL, which causes signal 1120 to be transmitted to 
different destinations- In another embodiment of the 

5 invention, each of the choices is merely identified and 
reflected within signal 1120. Accordingly, display module 
1124 extracts the selected choice from signal 1120 and 
generates the display signals to create a GUI screen that is 
responsive thereto . 

0 FIGURE 12 is a table illustrating a method within a TKET 

server for generating a GUI screen display at a remote 
terminal according to one embodiment of the invention. In 
the described embodiment, the display module of TKET server 
102 analyzes the terminal type to select from one of at least 

5 four different display types. For example, as is shown in 
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column 1204, desktop computers and laptop computers receive a 
set of display signals for generating a ''full" GUI screen 
display- In other words, a fully defined GUI screen display 
is generated at the remote terminal responsive to a set of 
signals that cause such a display being received by the 
remote terminal and transmitted by the TKET server. Column 
1208, however, illustrates a reduced set of display signals 
that might be transmitted to what is being referred to herein 
as a mini laptop. A mini laptop, as defined herein, is a 
device that, in terms of data storage and processing 
capacity, is somewhere between a PDA such as a Palm Pilot® 
and a laptop computer. Many companies are now starting to 
produce very powerful PDA' s that contain communication 
transceivers capable of supporting reasonably high data 
throughput rates but that do not provide the power and speed 
of a modern laptop. 

Column 1212 illustrates that for certain types of 
terminals, such as a PDA, a minimal set of display signals 
are to be transmitted thereby resulting in the user terminal 
displaying a minimal GUI screen display. For example, if the 
user terminal is a wireless PDA, then a set of display 
signals that would generate a minimal GUI screen display are 
transmitted by the display module of the TKET server. 
Finally, if the terminal is merely a telephone having a very 
limited display capacity, as is shown in column 1216, the 
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display signals may comprise little more than text and 
control signals for the text. Alternatively, if the user 
terminal is a telephonic device, the "'display signals" may 
comprise nothing more than voice information generated by an 
5 IVR. Alternatively, the display signals for phones might be 
a combination of text and voice signals. 

For each of these types of devices, there are multiple 
ways that the display module and/or other modules within the 
TKET server 102, of FIGURE 1 for example, may determine the 

10 type of user terminal. The protocol being used by the 
terminal in establishing a communication link with the TKET 
server can be very revealing as to the type of terminal. For 
example, if TKET server 102 of FIGURE 1 receives a signal 
from the network, it analyzes the received signal to 

15 determine whether the remote user terminal is using an HTML, 
an HDML or a WAP protocol for communicating. If the terminal 
is using HTML, then it probably is a device having the 
capability of a desktop, a laptop or other similar computer. 
If the protocol is a WAP protocol, then the TKET server may 

20 determine that the communication path includes a wireless 
link. If the protocol is an HTML protocol, the TKET server 
may determine that the backup user terminal is a PDA. 

FIGURE 13 is a table illustrating a method for 
determining whether to generate a set of signals for 

25 displaying either a full, reduced or minimal GUI screen 
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display based upon communication path characteristics 
according to one aspect of the present invention. Referring 
now to the exemplary system described FIGURE 13, it is seen 
that one of at least three different display modes of full, 
reduced and minimal are illustrated in columns 1304, 1308 and 
1312, respectively. It should be understand the invention 
includes having different numbers of display nodes. 
Additionally, rows 1316, 1320 and 1324 illustrate different 
communication path characteristics that influence the display 
mode or type of GUI screen display screen that is generated 
by the TKET server. 

Examining row 1316, if the communication link is an 
integrated services digital network (ISDN), a Tl, a new 
generation wireless (for example, 3G) communication link or 
if the communication link is transceived by a modem having a 
modem bit rate that eguals or exceeds 56K, then the TKET 
server generates a full. GUI screen display. Alternatively, 
if the user terminal modem is slower than a 56K modem or a 
wireless communication link that is older than a 3G wireless 
communication link, then the TKET server generates a reduced 
GUI screen display. Alternatively, if the wireless 

communication link includes transmission from a satellite 
system, the known latencies associated with satellite 
transmissions as well as the expense for a satellite link 
prompts the TKET server to transmit a minimal set of display 
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signals that will prompt the receiving user terminal to 
generate a minimal GUI screen display. 

Referring now to row 1320, it may be seen that the 
number of gateways can also influence whether a full, reduced 
or minimal set of display signals are transmitted for the 
generation of the GUI screen display screen. In one 

embodiment of the present invention, if the display signals 
have a communication path that includes only a number of 
gateways that is less than a defined number "A", then a full 
GUI screen display is transmitted unless there is a different 
reason for reducing the magnitude of the GUI screen display 
screen. However, if the number of gateways is within a 
range, by way of example, between the numbers A and B, then a 
reduced set of signals are transmitted to create a reduced 
GUI screen display. Finally, if the number of gateways 
exceeds the number B, then a minimal set of display signals 
are transmitted to create a minimal GUI screen display. In 
one described embodiment, A is set equal to one and B is set 
equal to three. 

Row 1324 illustrates that geography may' also be used to 
determine whether to transmit a full, reduced or minimal set 
of display signals to create corresponding GUI screen display 
screens. For example, if the display signals are being 
transmitted through the various networks to a geographic 
location that is within the North American continent, then a 
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full set of display signals are transmitted. 



If. 
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the 



other hand, the signals are being transmitted either to 
Central America, South America or Europe, then a reduced set 
of display signals are transmitted to create a reduced GUI 
screen display screen. Finally, for all other locations, by 
way of example, the Far East, the Middle East or Australia or 
New Zealand, then a minimal set of display signals to create 
a minimal GUI screen display screen are transmitted. In 
summary, therefore, the table of FIGURE 13 illustrates that 
the type of communication networks, the number of gateways, 
and the geographic location of the receiver or user are all 
significant parameters in determining whether to transmit a 
full, reduced or minimal set of display signals to create the 
corresponding full, reduced or minimal GUI screen display 
screens in a preferred embodiment of the invention. It is 
understood, of course, that geographic ' restrictions are 
exemplary. Moreover, even if there are actual restrictions 
today, improvements in data transport technologies will lead 
to different geographic constraint parameters. 

FIGURE 14 is a flow chart/ that illustrates a method 
ccording to the present inven/ion. Referring now to FIGURE 
14, the method may be explained in view of the various 
networks illustrated in FLGURE 1. For the present method, 
TKET server 102 is operalSle to receive calls that originate 
from landline phones, b/ way of example, phone 124 coupled to 
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a telephone network 106, and calls that ori/ginate from a 
wireless terminal, e.g., wireless terminal 3^0, 121, or 122 
in a wireless network 110. Each of the^e calls, in the 
described embodiment are transmitted through a gateway device 

5 similar to gateway device 108 of -FIGURE 1 where they are 
converted from an original form (e.g/. analog, time division 
multiple access (TDMA) , code divisi/n multiple access (CDMA) ) 
and put into an IP packet format/ to be transmitted through 
the internet 104 directly to TKCT server 102. 

0 In the described example/ TKET server 102 is coupled to 

communicate with an integ/ated voice response unit 138. 
Accordingly, when TKET server 102 receives data packets from 
internet 104 that originafted from a phone, by way of example, 
telephone 124, or wireless terminal 120, TKET server 102 

5 prompts IVR 138 to pl/ay a request for an ID. IVR 138 either 
produces that vo±cp request in a digitized form or analog 
form. If it is j/roduced in an analog form, TKET server 102 
is operable to /convert the analog signal to digital and to 
transmit it o/er the internet 104 through the corresponding 

0 gateway 108 /or 112 to the telephone 124 or wireless terminal 
120. According to the type of system, the signal is 
eventually converted to an analog signal for playing through 
a phone^ speaker. Thus, the initial message generated by IVR 
138 iA to prompt the user to state or enter his ID (step 

5 14O20. 
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Thereafter, through the network and various conversions 
described above, TKET server 102 receives and stores the 
response (step 1404). The manner of receiving and storing 
responses from IVRs is known. Thereafter, the TKET server 
prompts the IVR to play a message to prompt the user to 
select either start or stop (step 1406) . The response is 
then stored (step 1408) . Additionally, TKET server prompts 
the IVR to reguest an account code, which is then played and 
transmitted to the user (step 1410) . Again, the response is 
stored (step 1412) . 

As may be seen from examinin/g the method of FIGURE 14, 
the invention includes a TKET server that is coupled to an 
IVR to prompt the IVR to play /select messages. The select 
messages are then placed into /a digital form, transmitted in 
data packets through the inyernet and then converted by a 
gateway into a format that Is appropriate for the telephone 
network through which they are to be transmitted. 
Thereafter, the converted /signals are transmitted through a 
telephone network to the destination user terminal telephone. 

In an alternate embodiment of the invention, many of the 
computer instructions that, upon execution, result in the 
method steps being performed, may also be implemented within 
a telecommunication switch. For this embodiment, the switch 
itself is coupled to the IVR to generate the messages. The 
computer instructions stored within the switch would then 
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prompt the IVR to request an ID, request the user to select 
between start and stop, and to request the IVR to enter a 
message to request the user to enter an account code, and 
finally to store each of the responses as shown in steps 1404 
through 1412. An additional step, however, is that the 
switch must generate and transmit a message to the TKET 
server containing the user ID, the start/stop selection, and 
the account code at a minimal so that the TKET server may 
start or stop tracking time as is appropriate. Thus, step 
1414 is indicated as optional depending on what device 
performs the inventive method. 

If the inventive method is performed by a 
telecommunication switch, then, in the preferred embodiment, 
the generated message is formed using an HTTP protocol and is 
transmitted over the internet. 

FIGURE 15 is a flow chart illustrating an inventive 
method for receiving time tracking signals from a 
telecommunication switch according to a preferred embodiment 
of the invention. Referring now to FIGURE 15, the method 
includes receiving the message (step 1502). As described 
before, in the preferred embodiment of the invention, the 
message is received using an IP protocol. The TKET server 
then extracts the user ID (step 1504), extracts the account 
code (step 1506) , and extracts the start/stop status (step 
1508) . Thereafter, the TKET server stores the time entry 
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event that is defined by the extracted signals from steps 
1504 through 1508 (step 1510) . Thus, in relation to an 
account code, the user ID is stored along with a start/stop 
status. The TKET server also determines the total amount of 
time that the user entered for the given account code. 

In addition to extracting the account code, start or 
stop status and the user ID, the TKET server evaluates 
whether additional information is required. If additional 
information is required, then it generates a GUI screen 
display signal to request information according to terminal 
type (step 1512). For example, if the terminal type is a 
telephone, then the display signals will comprise little more 
than text. If the terminal is a desktop or lap top computer, 
then the TKET server will generate a set of display signals 
to cause the user terminal to generate a full GUI screen to 
request additional information. 

FIGURE 16 is a functional block diagram illustrating a 
network for facilitating timely electronic time entries and 
approvals according to a preferred embodiment of the 
invention. Referring now to FIGURE 16, a TKET server 1604 is 
coupled to communicate with a plurality of employer terminals 
1608 including an accounting department terminal 1612, an 
employee manager's terminal 1616 and an employee's terminal 
1620. The TKET server 1604 specifically exchanges time 
entries and billing information with each of the employer 
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terminals 1608. Additionally, TKET server 1604 is coupled to 
communicate with a contract employer terminal 1624 to 
transmit billing information thereto. 

TKET server 1604 include an award processing module 1628 
for determining whether an employee of the employer, e.g., an 
employee manager, has approved employee time entries 
according to a process and by a deadline to qualify the 
employee manager for a specified award. More specifically, 
an internal storage device of TKET server 1604 includes 
computer instructions that define the specific process 1632 
that must be followed for entering and approving time that 
qualifies the manager for an award. Additionally, the 
storage device stores a schedule 1636 that defines the 
deadlines by which entries must be made and approved to 
qualify the employee (here, the manager) for an award. 

In operation, the employee terminal 1620 communicates 
with TKET server 1604 to obtain GUI screen display signals 
that include account codes to which the employee may charge 
his time. The employee responds by entering time entries in 
the provided fields or objects of the GUI screen created by 
the TKET server 1604. The entered time is therefore 

transmitted to the TKET server with an indication that they 
are final and are to be submitted for payment. 

Upon receiving the final time entries from the employee, 
the TKET server transmits the time entries to the manager 
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terminal 1616 of employer terminals 1608 for approval. Upon 
receiving an approval from the manager terminal 1616, TKET 
server sends a summary of approved time entries to the 
accounting terminal 1612 and to the contract employer 
5 terminal 1624 if the employee of employee terminal is a 
contract employee of the employer of employer terminals 1608 
and is actually employed by contract employer 1624. 

In response to the various time entries, approvals and 
reports listed above, an accounting department will issue a 
10 check to the employee if the employee is a direct employee of 

9 

the company. If the employee is a contract employee, the 
contract employer generates a paycheck to the employee 
responsive to contract employer terminal 1624 receiving the 
approved time entries from TKET server 1604. Additional, and 

15 responsive to receiving the approved time entries, the 
contract employer terminal 1624 initiates an invoice to the 
accounting department (in the described example) of the 
employer for payment for the contract employee's labor. 

FIGURE 17 is a flow chart illustrating a method for 

20 entering and approving time entries according to a preferred 
embodiment of the invention. Initially, a TKET server 
receives time entries from an employee (step 1702) and, 
responsive thereto, transmits the time entries to an employee 
manager for approval (step 1704), It is understood that the 

25 employee must log in to the TKET server through his employee 
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terminal to establish a connection and to transmit the time 
entries thereto as described herein this disclosure. 
Similarly, the employee manager must log in through his 
terminal and establish a connection to receive the time 
entries for approval as is described herein this disclosure. 

After transmitting the time entries to the employee 
manager, the TKET server receives an indication that the 
manager has approved the time entries (step 1708) . After 
receiving approval, the TKET server transmits the approved 
time entries to an accounting department terminal (step 
1712), to a contract employer (step 1716) if the employee is 
a contract employee that is a direct report to the contract 
employer. Thereafter, the TKET server determines if the 
employee that is subject to qualifying for an award, e.g., 
the employee manager, entered the time entry approval by a 
specified deadline (step 1720) and whether the review and 
approval was- conducted according to a prescribed process 
(step 1724). If the specified conditions were satisfied, the 
TKET server issues an award (step 1728) . In the preferred 
embodiment of the invention, the TKET server maintains a bank 
of frequent flyer miles that were purchase or obtained from 
an airline for use as an award to the employees that use the 
system in the preferred manner. 

The inventive method and apparatus disclosed herein are 
particularly advantageous in that they provide a capability 
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for encouraging employees to utilize the capabilities of the 
present inventive system to make time entries and approvals 
on a timely basis in order to facilitate accurate and prompt 
time keeping. Such a process enables accounts to be promptly 
5 credit and/or paid for employee labor. It also enables 
managers to maintain better control on expenses and budgets. 

FIGURE 18 is a functional block diagram illustrating the 
circuitry within a time keeping and expense entry server 
according to one embodiment of the present invention. As may 

10 be seen, a TKET server 1800 includes a processor 1804, a 
memory 1808, a temporary memory 1812, and a bus controller 
1816, each of which is connected to a bus 1820. Memory 1808 
is formed of a hard drive while temporary memory 1812 is 
formed of random access memory. In general, memory 1808 is 

15 for storing computer instructions that define the operational 
logic of the server 1800 as described herein this application 
with particular reference to the illustrated methods and 
processors. Thus, processor 1804 receives the computer 
instructions by way of bus 1820 and executes them. The 

20 processor, as needed, temporarily stores data, by way of bus 
1820, within temporarily memory 1812. The processor may be 
any known type of processor. While the permanent memory in 
the described embodiment is a hard drive, any type of memory 
capable of retaining information through power cycles may be 

25 used. As may also be seen, a network interface 1824 is 
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connected to the controller 1816 to enable the server 1800 to 
communicate with other external devices. 

The modules described in this application are formed 
logically by the processor' s execution of the stored computer 
5 instructions. The server and/or modules may, in alternate 
embodiments, be implemented by application specific 
integrated circuits or other known circuit design approaches 
made to implement a specified logic design. 

While the invention is susceptible to various 

10 modifications and alternative forms, specific embodiments, 
thereof have been shown by way of example in the drawings and 
detailed description- It should be understood, however, that 
the drawings and detailed description thereto are not 
intended to limit the invention to the particular form 

15 disclosed, but on the contrary, the invention is to cover all 
modifications, equivalents and alternatives falling within 
the spirit and scope of the present invention as defined by 
the claims. As may be seen, the described embodiments may be 
modified in many different ways without departing from the 

20 scope or teachings of the invention. 



63 



